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REMARKS 

SECTION 112 REJECTION 

Claims 1, 3-6, 8, 1 1-32, and 36-38 were rejected under 35 U.S.C. 1 12. 
The claims recite 

detecting at a server, in real-time, a modification to locally-stored data 
occurring at a second client; 

sending a call from the first client to the server to enforce rules involving 
multiple users based on detecting the modification to locally-stored data that 
occurred at the second client, the call being sent before the modified data has been 
saved to a master representation of the hierarchy on the server; and 

These features are supported is by the specification as originally filed. For example, 

For the application server rule enforcement, rule enforcement module 140 sends 
the requested change to application 105 over network 120 using a proper call to 
cause program 105 to check the unique identifier against changes application 105 
is tracking at other clients that have not been saved to master hierarchical 
reference data 160.' 

Program 105 resides on the server.^ The specification fiirther states that 

Rule enforcement module 140 can verify in real-time that the entered member 
code and member description for new member 410 does not conflict with any 
other members in master hierarchical reference data 160 by sending a proper call 
to apiplication 105 (e.g., perform the application server rule enforcement and the 
master data rule enforcement described above).^ 

Thus, the application discloses "detecting at a server, in real-time, a modification to locally- 
stored data occurring at a second client[.]" The application further states that 

Application 105 tracks, for example, what hierarchies are being updated, who is 
doing the updating, and what new member codes and/or descriptions are being 
created. In one example, rule enforcement module 140 transmits each 
modification, and anv other information application 105 is collecting, to 
application 105, even though the user has not saved (e.g., pressed button 243g of 
screenshot 200) those modifications to master hierarchical reference data 160. By 



' Specification, page 10, lines 4-8. 

^See, e.g.. Figure 1. 

^ Specification, page 20, lines 5-9. 
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tracking this data on a real-time basis, application 105 can provide several 
additional features for managing hierarchical reference data."* 

Thus the application also disclose "the call being sent before the modified data has been saved to 

a master representation of the hierarchy on the server [.]" 

Accordingly, the appUcants request that rejection of claims 1, 3-6, 8, 1 1-32, and 36-38 

under 35 U.S.C. 112 be withdrawn. 



SECTION 103 REJECTION OF CLAIMS 1, 30, 31, AND 38 

Claims 1, 3-6, 8, 1 1-32, and 36-38 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Pat. No. 7,062,532 ("Sweat") in view of U.S. Pat. No. 6,240,414 
("Beizer"). 

Sweat fails to disclose "detecting, at a server, in real-time, a modification to locally-stored 
data occurring at a second client 

Claim 1 recites 

"detecting at a server, in real-time, a modification to locally-stored data 
occurring at a second client; 

sending a call from the first client to the server to enforce rules involving 
multiple users based on detecting the modification to locally-stored data that 
occurred at the second client, the call being sent before the modified data has been 
saved to a master representation of the hierarchy on the server[.]" 

Sweat has not been asserted to disclose a detection step as recited above in which the detection 

takes place "at a server". 

Beizer also fails to disclose "detecting, at a server, in real-time, a modification to locally- 
stored data occurring at a second client 

Beizer does not disclose a detecting step as recited in claim 1 . Rather Beizer describes t 

process for editing files and folders in which 

a local copy 54 is transferred from the shared storage 50 to a local storage area 
56 wliere it is readily accessible and may be modified by the user. Often, the 
original local copy of the WorkFolder 54 is preserved when the WorkFolder is 
edited and a separate local edit copy 58 is created. When the local edited 
WorkFolder 58 is saved, it can be compared to the local original copy 54 to 



* Specification, page 22, lines 12-19. 
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determine what changes were made by the user and also compared to the master 
copy 52, which may itself have been changed by a second user in the interim.^ 

This is consistent with the text cited by the Examiner in which 

As an example, users 1 and 2 simultaneously open the same WorkFolder. User 
1 attaches a document to the WorkFolder and changes a status data field to 
"completed." User 2 simultaneously opens another document in the WorkFolder 
and, based on its contents, enters the value of several other WorkFolder fields, 
i.e., current disbursements and income. Because neither user changed the same 
objects in the WorkFolder, the changes do not conflict with each other. Therefore, 
the changed and added data can be merged into the master WorkFolder. If both 
users change the same data field, i.e., user 1 changes the status field to "complete" 
while user 2 changes it to "on hold", and then both try to save the updated 
workfolder to the network storage area, the reconciliation logic detects the 
conflict and invokes an attended conflict resolution routine wherein one or both of 
the user's are prompted with a list of the conflicting changes and then asked to 
resolve, for each detected conflict, which of the conflicting values should persist 
in the master copy 52.^ 

It is apparent fi-om the foregoing passage that conflict checking does not actually occur 
until and unless a user attempts to save his edits.^ Therefore, "detecting. . .a modification to 
locally-stored data" can only occur once the user saves his edits. This can occur long after the 
edits were actually made. Such a detection step, which can come hours after an edit has been 
made, cannot reasonably be regarded as detection "in real time." Consequenfly, Beizer does not 
disclose "detecting at a server, in real-time, a modification to locally-stored data occurring at a 
second client[.]" 



^ See e.g., Beizer col. 5, line 46 - col. 6, line 3. 
^ See e.g., Beizer col. 6, lines 17-34. 

^ See also, e.g., Beizer, col. 6 line 64 - col. 7, line 22 ("According to the attended mediation scheme of the present 
invention, the last party to save their WorkFolder will be notified of the conflict when the WorkFolder is saved and 
presented with conflict resolving information, including for example, the two conflicting values of field B and the 
name of the other party to the conflict. In this situation, if user 2 was last to save, a notification would be provided 
that the changes to field B conflicted with data entered by User 1. User 2 would then be asked to choose between the 
conflicting data values. It is understood that User 1, as well as third party users, may also be notified of the conflict 
and permitted to participate in the conflict mediation process. In addition, priority may be assigned to users, so that, 
for example, User 2 may be able to override a change made by user 2, but not by user 1 . To facilitate this exchange, 
a log of changes to a WorkFolder, including the changed element and the name of the user who made the change, 
may be generated. Preferably, this log is stored in a history "meta-element" associated with the specific 
WorkFolder. Other log elements, such as the time a change was made, the previous value of the field, etc., may also 
be recorded. FIG. 3c illustrates the state of the Master work folder 52, and the local and edited copies 54, 58 of user 
1, both before and after the reconciliation described above when the user 2 changes were saved first. Note that the 
local copy 54 of the updated WorkFolder for user 1 has not been refreshed to reflect the changes fi-om user 2." - 
emphasis added). 
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Neither Sweat nor Beizer, alone or in combination, disclose or suggest all of the features 
of independent claim 1 . Accordingly, a prima facie case of obviousness of claim 1 or of any of 
the associated dependent claims has not been established. Therefore, claim 1 is patentable over 
Sweat and Beizer, alone or in combination. 

Proposed modification of Sweat changes its principle of operation 

According to MPEP 2 1 43 .01 (VI) 

"If the proposed modification or combination of the prior art would change the 
principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious. In re Ratti, 270 
F.2d 810, 123 USPQ 349 (CCPA 1959)." 

Sweat discloses a system that relies on locking and unlocking files to control 

modification of files by multiple users. Sweat specifically states 

A user can view or download files from anywhere in the world to work on 
them, while locking the file to prevent others firom overwriting the file. When the 
user is done, the file can be uploaded and unlocked while simultaneously 
notifying other Project members of the change by e-mail.* 

In contrast, Beizer's objective was to allow "multiple users to simultaneously access and edit the 

same shared data object without requiring an object accessed by one user to be locked relative to 

later users."^ 

Both-Sweat and Beizer are directed to solving the same technical problem, namely 
allowing multiple users to edit the same data. However, one of ordinary skill in the art would 
have seen that the two achieve this objective in different and fimdamentally incompatible ways. 

The Examiner notes that Sweat "is silent about identifying conflict."^" But this is because 
when locks are used, only one person at a time can edit a file. Accordingly, no conflict can occur. 
One of ordinary skill in the art would have understood that Sweat "is silent about identifying 
conflict" for the simple reason that locks prevent conflicts. 

In contrast, Beizer specifically eschews the use of locks. As a result, multiple users can 
edit the same data at liie same time. This procedure, which is fundamentally different fi-om 



^ Sweat, abstract. 
* Beizer, col. 2, lines 54-57. 
Office Action, page 4, line 22. 
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Sweafs, practically invites conflict. It would therefore have come as no surprise to one of 
ordinary skill in the art that Beizer discusses conflict resolution at great length. 

One of ordinary skill in the art would therefore have regarded the proposed modification 
of Sweat to include Beizer' s conflict resolution techniques as making no technical sense. One of 
ordinary skill in the art would have recognized that Sweafs use of locks effectively prevents the 
conflicts that would arise in Beizer's lock-less system. 

Accordingly, Applicant submits that the proposed motivation to combine the references is 
flawed, and that the section 103 rejection is therefore improper. 

Claims 30, 31, and 38 include features similar to claim 1 and are patentable for at least 
the same reasons. Claims 3-6, 8, 11 -29, 32, 36, and 37 depend firom either claim 1 or claim 31 
and are patentable for at least the same reasons. Accordingly, the 103 rejection based on Sweat 
in combination with Beizer is improper and should be withdrawn. 

For at least the foregoing reasons, the applicants respectfully submit that the application 
is in condition for allowance. 

All of the dependent claims are patentable for at least similar reasons as those for the 
claims on which they depend are patentable. 

Canceled claims, if any, have been canceled without prejudice or disclaimer. 

Any circumstance in which the applicants have (a) addressed certain comments of the 
examiner does not mean that the applicants concede other comments of the examiner, (b) made 
arguments for the patentability of some claims does not mean that there are not other good 
reasons for patentability of those claims and other claims, or (c) amended or canceled a claim 
does not mean that the applicants concede any of the examiner's positions with respect to that 
claim or other claims. 
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Please apply any charges or credits to Deposit Account No. 06-1050, referencing 
Attorney Docket No. 08575-0094001. 

Respectfully submitted, 

' ' Sean M. Dean, Ph.D., J.D. 
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